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Encoding and Decoding of Sound Links 

Field of the Invention 

The present invention relates to the encoding and decoding of hyperlinks in sound signals. 
Background of the Invention 

In recent years there has been an explosion in the number of services available over the 
World Wide Web on the public internet (generally referred to as the "web"), the web being 
composed of a myriad of pages linked together by hyperlinks and delivered by servers on 
request using the HTTP protocol. Each page comprises content marked up with tags to 
enable the receiving application (typically a GUI browser) to render the page content in the 
manner intended by the page author; the markup language used for standard web pages is 
HTML (Hypertext Markup Language). 

However, today far more people have access to a telephone than have access to a computer 
with an Internet connection. Sales of cellphones are outstripping PC sales so that many 
people have already or soon will have a phone within reach where ever they go. As a result, 
there is increasing interest in being able to access web-based services from phones. 'Voice 
Browsers' offer the promise of allowing everyone to access web-based services from any 
phone, making it practical to access the Web any time and any where, whether at home, on 
the move, or at work. 

Indeed, because many items around the home and office have a sound capability, it is 
attractive to use sound, not only for passing information to / from / between humans, but 
also for passing functional information such as URLS, to and between items of equipment. 
JP 11-119974 (Sony) describes various ways of using sound URLs, these being DTMF 
sound sequences that decode to character URLs. 

A disadvantage of audible sound URLs is that they are generally highly unattractive to 
humans as they posses a fairly random structure of sound (or so it appears to the human 
ear). Whilst it is possible to hide sound data such as URLs in other, pleasanter sounds 



using sound watermarking techniques, this generally requires complex embedding and 
retrieval systems which is expensive. 

It is an object of the present invention to provide improved sound URLs and methods for 
their usage. 

Summary of the Invention 

According to one aspect of the present invention, there is provided a method of encoding a 
URL in sound, wherein the characters of the URL are mapped to sound features in a sound 
output, the nature of the sound features and of the mapping between characters and sound 
features being such that at least certain character combinations that occur frequently in 
URLs produce sound sequences of a musical character. 

According to another aspect of the present invention, there is provided a method of 
decoding a sound sequence into a URL, wherein sound features of the sound sequence are 
mapped to characters of the URL, the nature of the sound features and of the mapping 
between sound features and characters being such that sound sequences of a musical 
character represent at least certain character combinations that occur frequently in URLs. 

According to a further aspect of the present invention, there is provided apparatus for 
encoding a URL in sound, the apparatus comprising a translator for mapping characters of 
the URL to sound features in a sound output, the nature of the sound features and of the 
mapping between characters and sound features being such that at least certain character 
combinations that occur frequently in URLs produce sound sequences of a musical 
character. 

According to a still further aspect of the present invention, there is provided apparatus for 
decoding a sound sequence into a URL, the apparatus comprising a translator for mapping 
sound features of the sound sequence to characters of the URL, the nature of the sound 
features and of the mapping between sound features and characters being such that sound 
sequences of a musical character represent at least certain character combinations that 



occur frequently in URLs. 
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Brief Description of the Drawings 

A method and apparatus embodying the invention, for encoding and decoding sound 
URLS, will now be described, by way of non-limiting example, with reference to the 
accompanying diagrammatic drawings, in which: 

. Figure 1 is a block diagram showing the main functional blocks of a tone URL 
translator; 

. Figure 2 is a diagram illustrating the mapping between tones and characters for a 

first tone-URL encoding/decoding scheme; 
. Figure 3 is a diagram illustrating the mapping between tones and characters for a 

second tone-URL encoding/decoding scheme; 
. Figure 4 is a diagram illustrating a preferred conversion scheme between characters 

and sound codewords; 
. Figure 5 is a diagram showing the use of a service system to translate site codes to 

site URLs; and 

. Figure 6 is a diagram showing the use of the Figure 5 service system by a network 
voice browser. 



Best Mode of Carrying Out the Invention 

Figure 1 depicts a tone URL translator 1 for receiving a sequence of tones that encode the 
characters of an URL. The tones are received as sound through microphone 2 but may also 
be received in analogue or digital electrical signal form. A converter 3 converts the 
received tone signals into a common internal format before passing the tone signals to a 
unit 4 that determines the frequencies of the received tones and generates corresponding 
respective tone codewords. These sound codewords are supplied to unit 5 where they are 
converted into a URL character string according to a predetermined mapping process. 

Figure 2 shows a first mapping scheme for converting between tones and character codes. 
In this example, there is a one-to-one correspondence between tones and character codes - 
that is, each tone maps to one character code. In Figure 2, the left-hand column shows the 
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set of available tones 6 in increasing order of frequency, the center column corresponds to 
the set of tone codewords 7 arranged in increasing codeword value, and the right-hand 
column is the set of character codes in standard order (for example, the ASCII character 
code set arranged in increasing order of binary value). 

5 

Moving from a tone to a character code (or vice versa) involves two mappings, namely a 
first mapping 9A between tone and tone codeword, and a second mapping 9B between tone 
codeword and character code. The overall mapping between tones and character codes is a 
combination of the two mappings 9 A and 9B. In the Figure 2 example, both mappings 9A 
1 0 and 9B are simple one-to-one mappings with the values on each side of the mappings both 
increasing /decreasing as the sets 6,7 and 8 are progressed through. 

Implementing the Figure 2 scheme using the Figure 1 translator involves the unit 4 carrying 
out the mapping 9 A and unit 5 carrying out the mapping 9B. 

15 

Whilst the foregoing mapping of Figure 2 is extremely simple and therefore easy to 
implement, it suffers from the disadvantage that the sequence of tones produced when any 
particular URL is encoded, is likely to be unpleasant to the human ear. 

20 To alleviate this, a modified mapping is used, one example modified mapping being 
illustrated in Figure 3 . In this example, the mapping 9 A between tones and tone codewords 
is modified such that the overall mapping between tones and character codes results in 
frequently used character combinations of URLs producing pleasant sound sequences (that 
is, sequences of a musical character where "musical" is to be understood broadly, including 

25 chimes and the like). The character combinations so encoded are, for example, the generic 
top level domain names and "www". 

The mapping 9B could alternatively or additionally have been modified to produce the 
desired musical sequences. 

30 

It is also possible to choose a mapping that gives a musical sequence for a complete URL. 
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In the foregoing encoding/decoding schemes, there is a one-to-one correspondence 
between tones and character codes and, as a consequence, it is possible to omit one of the 
mappings 9A / 9B and have tones mapping directly to character codes. However, using 
intermediate tone codewords gives a degree of flexibility permitting improved encoding. 

5 

More particularly, if the character set has 256 characters, then producing 256 tones within 
the frequency band of a telephone voice circuit (over which it maybe desired to pass sound 
URLs), means that the resultant tones are very close together. It is preferable to have a 
smaller number of tones - for example 64 tones. However, to efficiently code characters in 
10 this case requires that each group of three characters is encoded by four tones. How this 

hk can be conveniently done is illustrated in Figure 4 where each of three characters is 

represented by an 8-bit code. These codes are concatenated to form an intermediate 24-bit 
word 50. Word 50 is then split into four 6-bit tone codewords; the 6 bits permit 64 possible 

y tone codewords which therefore provide an efficient representation of the 64 tones. 

s * 15 

f Figure 4 represents a four-to-three mapping between tone codewords and character codes 

flj (mapping 9B), the mapping 9A between tones and tone codewords remaining a one-to-one 

% in this example (though this can be varied). With this encoding scheme, it is more 

complicated to determine the details of the mapping (for example, mapping 9A) required to 
20 generate pleasant tone sequences for particular character groups since the characters must 
be considered in groups of three. However, since the main target character groups (generic 
top level domain names) are three-character groups and since leading spaces can be used to 
ensure that each such group is taken as a whole during the encoding process, determining a 
mapping for producing pleasant sounds for a small set of character combinations is a 
25 manageable task. 



Whilst the mappings used by block 4 and 5 can conveniently be effected using simple look- 
up tables stored in memory, it is possible to use other mappings arrangements; for 
example, at least where only a small number of character combinations are required to 
encode to musical sequences, it will generally be possible to find transformation functions 
that can be calculated to derive the desired mappings. 
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It will be appreciated that the encoding process by which URL characters are converted to 
tone sequences is the reverse of the above-described decoding processes carried out by 
translator 1 and can be effected by appropriate decoding apparatus. 

Rather than the above-described sound sequences encoding URLs, they can alternatively be 
used to encode URNs (Uniform Resource Names); in general terms, the sound sequences 
encode URIs (Uniform Resource Names). 

Figure 5 shows an arrangement which also enables pleasant tone sequences to be used to 
pass URLs; as will be seen, this arrangement preferably, but not necessarily, makes use of 
tone-character mappings such as depicted in Figure 3 which associate pleasant tone 
sequences with common character sequences. 

More particularly, end-user equipment 10 has a web browser 11 which can be used to 
contact web sites over the internet 20. Equipment 10 is provided with a sound input 
microphone 1 3 for receiving sound sequences 12 which represent, or can be used to obtain, 
website URLs. The sound sequences are constituted by tone sequences representing 
characters according to mappings such as illustrated in Figure 2, 3 and 4. The sound 
sequence signals from microphone 1 3 are passed to translator 1 4, which is similar in form 
to translator 1 of Figure 1, and the resultant character sequences are fed to a discriminator 
unit 15. The role of this unit 15 is to determine whether a received character sequence 
represents a general URL (in which case it is passed to browser 1 1 for use in accessing the 
corresponding website), or whether it represents a site code intended to be translated into a 
URL; in the present example, service system 25 with URL "mapmusic.com" provides such 
a translation service. 

The sound sequence 12 depicted in Figure 5 corresponds to the input of a site code. The 
sound sequence is made up of four segments, namely a "start" segment 12A which can be a 
special character sequence indicating the start of a sequence, a sound segment 12B that 
encodes characters indicating that a site code is being provided, a sound segment 12C 
encoding the site code itself, and a stop segment indicating the end of the sequence 12. The 
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start and stop codes would typically also be used to delimit a tone sequence directly 
encoding a URL. 

When the discriminator sees the characters indicative of a site code, it knows that the next 
set of characters constitutes the site code and this code requires translation into a URL. The 
indicator characters can, in fact, be the URL of the translation service system - in this 
example "mapmusic.com". 

The discriminator 1 5 next passes the site code to unit 1 6 which proceeds to contact service 
system 25 over the internet 20 (see arrow 22), passing it the site code 1 8. A map-site-code 
block 26 at service system 25 does a simple database lookup in database 28 to convert the 
site code into the corresponding site URL which it then returns to the unit 16 (see arrow 
23). Unit 23 then passes the URL to browser 1 1 which uses it to contact the website 
concerned - in this case, website 40. 

The Figure 5 arrangement permits the use of site codes chosen because they sound pleasant 
when encoded into sound, the corresponding code characters being of little relevance 
provided they are unique. Furthermore, if the mapping used in the encoding scheme has 
been selected such that both the start and stop segments, as well as the "mapmusic.com" 
URL all have pleasant sounds, then the sound sequence 12 will be acceptable to the human 
ear regardless of the site being pointed to. 

In the same way as the sound sequences supplied to translator 1 in Figure 1 can represent 
URIs rather than just URLs, the service system can be arranged to translate site codes into 
URIs rather than URIs. 

Figure 6 shows a variation of the Figure 5 arrangement in which the functionality of 
equipment 10 is incorporated into a voice browser 33 located in the communications 
infrastructure (for example, provided by a PSTN or PLMN operator or by an ISP). A voice 
browser allows people to access the Web using speech and is interposed between a user 32 
and a voice page server 60. This server 60 holds voice service pages (text pages) that are 
marked-up with tags of a voice-related markup language (or languages). When a page is 
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requested by the user 32, it is interpreted at a top level (dialog level) by a dialog manager 
37 of the voice browser 33 and output intended for the user is passed in text form to a 
Text-To-Speech (TTS) converter 36 which provides appropriate voice output to the user. 
User voice input is converted to text by speech recognition module 35 of the voice browser 
5 33 and the dialog manager 37 determines what action is to be taken according to the 
received input and the directions in the original page. Whatever its precise form, the voice 
browser can be located at any point between the user and the voice page server; in the 
present case, it is shown as located in the communications infrastructure. 

1 0 The sound channel between the user' s equipment 3 1 (for example, a mobile phone) and the 
voice browser 33 permits a tone-encoded character sequence be passed to the browser. This 
tone sequence is intercepted by unit 38 and passed to functionality corresponding to units 
1 4, 1 5 and 1 6 in Figure 5 . If the tone sequence includes a general URL this is passed to the 
browser for action, whereas if the tone sequence includes a site code, the service system is 

1 5 accessed to determine the corresponding URL, the latter being returned and passed to the 
browser. 

In both the arrangements of Figures 5 and 6, the unit 1 6 preferably includes a cache which 
is used to store the site codes and their corresponding URLs received back from the service 
20 system 25. In this case, before the unit 16 accesses service system to get a translation of a 
newly-received site code, it first checks its cache to see if it already has the required URL 
in cache - if it does, the URL is passed to the browser without the service system being 
accessed. 

25 

Many variants are, of course, possible to the arrangements described above. For example, 
whilst the sound features used to represent the codewords 7 have been tones in the 
foregoing examples, the codewords could be used to produce a different type of sound 
feature, such as: 
30 - tone combinations; 

occurrence of maximum sound output power in predetermined frequency bands; 

changes in output frequency; 
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different modulation frequencies of one or more tones. 
Furthermore, the sound features can occur not only sequentially as described, but also in 
overlapping relation provided that it remains possible to determine character sequencing on 
decoding of the sound URL. 
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